🗣 Description

This PR includes code and docker configuration for the building and operation of four VS Connectors for the running OpenCTI Platform in CAWS Staging.

VS Org Ingest Connector
This connector is an External Import connector, the connector pulls VS Organization data, CIDR data, and sector data from the RDS DB and creates a number of OpenCTI objects. OpenCTI entities are created to cover sectors and organizations as their respective names, CIDR data is broken down into the IP's within each CIDR range and these IP's are created as IPv4 Observables in OpenCTI. All three data entities are also linked together to ensure ownership is maintained.

VS Ticket Ingest Connector
This connector is also an External Import connector and pulls Ticket data from the VS data stored in the RDS DB. These tickets are broken down into IPv4 Observables and Vulnerabilities. The IPv4 Observables are linked to the correct organization.

VS Port Ingest Connector
This is the final External Import connector, and simply pulls from the latest_port_scan table, creating Observable IPv4 entities, Observable Network Traffic entities.
*The Network Traffic entity is restrictive and custom fields such as open, closed, service cannot be added. The VS data contains these fields and we should revisit this issue in the future to ensure we surface the same fields and capabilities with this data in OpenCTI.

VS VulnScan Connector
This connector is an Internal Enrichment connector and must be run manually over an Observable, a selection of Observables or a vulnerability. This connector essentially adds notes to the entity it performs enrichment on, including vuln scanning details such as open ports, additional vulnerability details and the like.

Each connector is isolated from the others and includes a dockerfile for building its container.

💭 Motivation and context

Resolves CRASM-4112

🧪 Testing

✅ Pre-approval checklist

• This PR has an informative and human-readable title.
• Changes are limited to a single goal - eschew scope creep!
• All future TODOs are captured in issues, which are referenced in code comments.
• All relevant type-of-change labels have been added.
• I have read the CONTRIBUTING document.
• These code changes follow cisagov code standards.
• All relevant repo and/or project documentation has been updated to reflect the changes in this PR.
• Tests have been added and/or modified to cover the changes in this PR.
• All new and existing tests pass.
• Bump major, minor, patch, pre-release, and/or build versions as appropriate via the bump_version script if this repository is versioned and the changes in this PR warrant a version bump.
• Create a pre-release (necessary if and only if the pre-release version was bumped).

✅ Pre-merge checklist

• Revert dependencies to default branches.
• Finalize version.

✅ Post-merge checklist

• Create a release (necessary if and only if the version was bumped).